1. Field of the Invention
The present invention relates to applications programming environment using markup languages such as XML, and more specifically to reducing programming complexity in applications interfacing with parsers for data elements represented according to a markup languages.
2. Related Art
Markup languages such as XML are generally used to represent various data of interest. A typical markup language generally contains tags which indicate one or more of various aspects such as what the data represents or how the data is to be displayed, etc. For example, in XML, relevant data is enclosed between a start tag and an end tag, indicating what the enclosed data represents. The relevant data and the tags are referred to as data elements in the present application.
Applications, which require data represented according to markup languages, often interface with a parser for the various data elements of interest. In a typical scenario, the XML data is stored in an XML data file, and the parser retrieves the data elements and provides the retrieved elements to the applications according to a pre-specified approach.
According to one pre-specified approach often referred to as ‘pull parsing’, an application generally requests that the ‘next’ data element be provided. In response, a parser retrieves (e.g., from an XML document) the next data element (in sequential order) from the XML data file and provides the next data element to the application. Since the data elements are generally retrieved in sequential order, the parsers are referred to as sequential parsers.
According to another sequential parsing approach, often referred to as ‘push parsing’, a parser retrieves data elements in an XML data file without necessarily receiving a request for a next data element, and “pushes” the retrieved data element to the application (after the application has specified the file identifier of the XML data file). The applications are designed to process such data elements received from the push-based parsers. SAX and XNI are the two industry standards, which support push parsing.
The pull and push based parses are broadly referred to as event based parsers since the requests (from application) of pull parsing and the pushing of data elements in push parsing can be viewed as events. It may be appreciated that the data elements are provided one at a time in event based parsing techniques.
In another broad prior approach, commonly referred to as ‘Object based parsing’, the parser generally creates a hierarchical representation of data elements in an XML data file while parsing the XML data file and saves the hierarchical representation (in the form of a data structure) of the data elements into a random access memory (RAM) which is accessible to the application. The memory resident data structure is referred to as DOM (Document Object Model). The object based parsers return the DOM to the application, typically after parsing of the XML data file is complete. Thus, the applications are designed to access the RAM for any desired data element thereafter. Two commonly used DOM standards are W3C DOM and J-DOM.
An advantage of the object based parsing over the event parsers is that the data elements are available quickly to the applications. However, the memory (RAM) requirements are substantially more since a data structure representing the entire XML data file may be saved in the RAM.
Applications often require an identifier (“portion identifier”) of portions (containing one or more data elements) of a data file. In the case of XML, the portion identifier is referred to as an XPATH, and is defined in a hierarchical fashion similar to the file paths in various computer systems. The portion identifier may be required, for example, to determine a parent/ancestor of a data element. As an illustration, assuming that an XML data file contains data related to a school and that a retrieved data element corresponds to the name of a student of a section, and it is desirable to determine the teacher of the section. The name of the teacher may be structured as an ancestor of the retrieved data element, and accordingly it may be desirable for an application to have the XPath of the name of the student.
In a prior approach, applications may include program logic to build/construct XPath (or portion identifier, in general) of such desired parts of an XML data file. The need to build such portion identifiers of data elements of interest generally adds to the programming complexity of applications. At least for such a reason, there is a general need to reduce programming complexity in applications interfacing with parsers for data elements represented according to markup languages.
In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.